-
Notifications
You must be signed in to change notification settings - Fork 6.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
arch/xtensa: arch_cpu_idle cleanup #64760
arch/xtensa: arch_cpu_idle cleanup #64760
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, I like this very much at a level of code hygiene and platform encapsulation. So it's a +1. But I'm going to repeat my question from earlier, because I really do hope we can find an answer:
Are we absolutely, 100% sure that this is a hardware issue that only affects Intel audio DSPs?
Upstream SOF on Intel is the original source for this trick, but the way it's documented there seems to imply that it's a more general bug with Cadence IP, even though no one else seems to know about it. If that's true, then we want this to stay in the arch layer so that affected SOCs from all vendors can take advantage of it.
So... are we? If not, can we get someone at Intel to ping Cadence for a proper errata reference or something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If that's true, then we want this to stay in the arch layer so that affected SOCs from all vendors can take advantage of it.
So... are we? If not, can we get someone at Intel to ping Cadence for a proper errata reference or something?
Mmmmm... shouldn't the next step be for someone OTHER than Intel to reproduce the issue first? I mean it feels at least "awkward" for User X to ask common vendor A about User Y issues.
FWIW I found Cadence support very responsive in this other, unrelated toolchain issue:
@@ -180,6 +180,52 @@ void pm_state_exit_post_ops(enum pm_state state, uint8_t substate_id) | |||
} | |||
#endif /* CONFIG_PM */ | |||
|
|||
#ifdef CONFIG_ARCH_CPU_IDLE_CUSTOM | |||
/* xt-clang removes any NOPs more than 8. So we need to set |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/* xt-clang removes any NOPs more than 8. So we need to set | |
/* xt-clang removes any NOPs more than 8. So we need to set |
Please provide at least one xt-lang version that with confirmed reproduction. This workaround should refer to a proper issue number but for now the mere output of xt-lang --version
will already be infinitely better than nothing.
If there was a past discussion in https://github.com/thesofproject/sof about this then also add the link. Toolchain issues are incredibly time-consuming so the last thing they need is incomplete information.
I realize you're "only" moving an existing comment but as noted by @andyross this PR does far more than just re-organizing code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think @dcpleung was the one who discovered that particular optimizer misfeature, likely on the MTL toolchain?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All the xt-clang I used exhibited the same behavior of "ignoring" NOPs beyond 8.
For LX6, WAITI instruction has some requirements, each vendor may have different solution to meet them. Due to intel dsp clock gating method and WAITI requirement, Intel audio hw use this workaround so that no hw hang would happen. Please check internal issue about the hw detail. updated : internal number 1804185050 |
arch/xtensa/Kconfig
Outdated
@@ -173,4 +173,11 @@ endif # XTENSA_MMU | |||
|
|||
endif # CPU_HAS_MMU | |||
|
|||
config ARCH_CPU_IDLE_CUSTOM |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this should not be xtensa specific, please move it up so any other architecture can do the same if needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nashif updated, thanks
d2a9535
to
cf5b1f8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall I think this is a good cleanup, but I think this has to be enabled by default for affected targets.
bool "Custom arch_cpu_idle implementation" | ||
default n | ||
help | ||
This options allows applications to override the default arch idle implementation with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure about this. Why would this be an application level override? It seems this is a board/soc specific requirement and if you buiild for these targets, the custom functions has to be used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kv2019i I tested cavs2.5 and didn't find any issue. I traced this issue which was found on cavs1.8 platforms in 2017 and then these patches was applied. I don't think it still exists on cavs2.5 so I don't enable it with cavs2.5. I reserve it since It will make effect when cavs1.8 platform are supported.
Each arch platform may has a general arch_cpu_idle implementation but each vendor may has a custom one, so this config will be used for vendor to override it. Some workarounds were introduced for intel cavs2.5 platform bring up. It is not general so move them to platform code. Signed-off-by: Rander Wang <rander.wang@intel.com>
Cavs platforms starts from Apllolake to Raptorlake. Some of them need some workaround for arch_cpu_idle so create a bespoken one. Each workaround is configured by kconfig setting. Signed-off-by: Rander Wang <rander.wang@intel.com>
cf5b1f8
to
1a3f305
Compare
remove "no optimization" |
Some workarounds were introduced for intel cavs2.5 platform bring up. It is not general so move them to platform code. Signed-off-by: Rander Wang <rander.wang@intel.com>
1a3f305
to
0b1b664
Compare
@dcpleung move CONFIG_XTENSA_CPU_IDLE_SPIN and CONFIG_XTENSA_WAITI_BUG to intel side. Thanks! |
@dcpleung could you help to review it ? thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @RanderWang , looks good now!
move some intel cavs platform code to intel platform folder